home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
TPUG - Toronto PET Users Group
/
TPUG Users Group CD
/
TPUG Users Group CD.iso
/
CRS
/
crs49.d81
/
hack#3b.sfx
/
hack#3-3.txt
next >
Wrap
Text File
|
1990-02-12
|
38KB
|
828 lines
╟EO╨AINT ╞ILE ╞ORMAT
--------------------
BY ┬RUCE ╓RIELING (BVRIELING@UNDERGRAD.MATH.WATERLOO.EDU)
╟EO╨AINT IS AN EXCELLENT GRAPHICS PROGRAM WRITTEN FOR THE ╟┼╧╙ ENVIRONMENT. ╔TS
DISK ACCESS IS RELATIVELY QUICK, COMPARED IT TO WHAT A COMPARABLE PROGRAM WOULD
DO ON A NON-╟┼╧╙ EQUIPPED ├64. ╨ART OF THIS ACCOMPLISHMENT CAN BE ATTRIBUTED TO
THE DISK╘URBO THAT IS AN INTEGRAL PART OF ╟┼╧╙. ╚OWEVER, THE SPECIAL ╟EO╨AINT
FILE-SAVING SCHEME DESERVES SOME OF THE CREDIT.
╓╠╔╥
----
╟EO╨AINT FILES ARE ALWAYS STORED IN ╓ARIABLE ╠ENGTH ╔NDEXED ╥ECORDING FILES.
╓╠╔╥ FILES OFFER ADVANTAGES NOT AVAILABLE WITHOUT ╟┼╧╙. ╟ENERALLY SPEAKING, ╓╠╔╥
IS THE ULTIMATE IN ╥┼╠┴╘╔╓┼ FILES.
╘HE FORMAT OF A ╓╠╔╥ FILE IS NOT THAT DIFFICULT TO FIGURE OUT. ╫HILE IN A
REGULAR ├64 FILE, THE TWO BYTES DIRECTLY FOLLOWING THE ╞╔╠┼╘┘╨┼ BYTE IN THE
DIRECTORY WOULD POINT TO THE DATA FILE FOLLOWING, ╓╠╔╥ FILES USE THESE TWO BYTES
TO POINT TO A ╓╠╔╥ ╚┼┴─┼╥ ┬╠╧├╦ (DON'T CONFUSE THE ╓╠╔╥ ╚┼┴─┼╥ BLOCK WITH THE
╔╬╞╧ BLOCK). ╘HE FIRST TWO BYTES OF THIS BLOCK ARE $00/╞╞, AS THE HEADER BLOCK
IS A ═┴╪╔═╒═ OF ONE BLOCK LONG. (╘HIS IS WHY WHEN YOU ╓┴╠╔─┴╘┼ A ╟┼╧╙ DISK FROM
├64 MODE, ╟EO╨AINT PICTURES ARE LOST. ╧NLY THE HEADER BLOCK IS RECOGNISED AS
BEING PART OF THE FILE. ╘HE REST OF THE PICTURE GETS DEALLOCATED IN THE ┬┴═).
╘HE REMAINING 254 BYTES IN THE BLOCK ARE DIVIDED INTO 127 2-BYTE POINTERS TO
TRACKS/SECTORS ON THE DISK. ╘HESE POINTERS POINT TO THE INDIVIDUAL RECORDS OF
THE ╓╠╔╥ FILE, WHICH MAY BE ┴╬┘ NUMBER OF BLOCKS LONG. ╘HE ╓╠╔╥ TRACK/SECTOR
POINTERS IN THE ╓╠╔╥ HEADER BLOCK ONLY POINT TO THE ╞╔╥╙╘ BLOCK OF THE CHAIN.
╞ROM THEN ON, THE SECTORS CHAIN THEMSELVES TOGETHER USING THE NORMAL FORMAT IE.
THE FIRST TWO BYTES OF EACH BLOCK POINT TO THE FOLLOWING BLOCK.
┴ SAMPLE ╟EO╨AINT ╓╠╔╥ HEADER MIGHT LOOK LIKE THIS:
0000:00 ╞╞ 03 11 03 05 03 01 ........
0008:04 03 00 ╞╞ 00 ╞╞ 00 ╞╞ ........
0010:04 07 00 00 00 00 00 00 ........
ETC....
╘HE FIRST TWO BYTES, $00/╞╞, TELL THE DRIVE THAT THIS IS THE LAST (AND ONLY)
BLOCK IN THIS ╓╠╔╥ ╚┼┴─┼╥ ╙┼├╘╔╧╬ (WILL NEVER BE MORE THAN 1 BLOCK, AS WAS
MENTIONED EARLIER). ╘HE NEXT PAIR OF BYTES, $03/11, POINTS TO THE FIRST ╓╠╔╥
RECORD. ╘HE NEXT TWO, $03/05, POINT TO THE SECOND RECORD.
┘OU WILL NOTICE THAT 5TH RECORD CONTAINS THE VALUES $00/╞╞. ╘HIS MEANS THAT FOR
THIS RECORD, THERE IS NO PICTURE DATA. ╫E WILL GET INTO EXACTLY WHAT THE DATA
HELD IN THE RECORDS MEAN IN A MINUTE. ╘HE $00/╞╞ ENTRIES INDICATE AN EMPTY
RECORD. ╞INALLY, THE 9TH ENTRY, $00/00 INDICATES THE END OF THE ╟EO╨AINT FILE.
╘HERE IS NO MORE DATA BEYOND THIS POINT.
╧NE NOTE SHOULD BE MADE. ╟EO╨AINT IS NOT ALWAYS CONSISTENT IN ITS HANDLING OF
THE DATA IN A HEADER BLOCK. ╙OMETIMES, IT WILL SHOW QUITE A FEW $00/╞╞
COMBINATIONS BEFORE FINALLY TERMINATING WITH A $00/00. ╫HEN READING THE FILE,
╔ ALWAYS READ THE ENTIRE HEADER, AS ╔ DON'T TRUST THE END OF FILE METHOD
MENTIONED ABOVE. ╩UST REMEMBER THAT ANY TRACK/SECTOR LINK THAT DOES NOT CONTAIN
$00/╞╞ OR $00/00 IS A VALID RECORD, WITH PICTURE DATA.
╠AYOUT ON ╙CREEN
----------------
╟┼╧╙ ORIENTS THE DATA IN A ╟EO╨AINT FILE SLIGHTLY DIFFERENTLY THAN IN A
╨HOTO╙CRAP OR AN ╔CON. ┴ PHOTOSCRAP STORES THE BYTES CORROSPONDING TO A SCREEN
WHICH LOOKS LIKE THIS:
001 002 003 004 005 ....0012
013 014 015 016 017 ....0024
├ONSECUTIVE BYTES ARE PLACED ┬┼╙╔─┼ EACH OTHER. ╚OWEVER, IF YOU ARE AT ALL
FAMILIAR WITH THE LAYOUT OF A ├64 HI-RES SCREEN, YOU WILL KNOW THIS IS VERY
DIFFERENT FROM THE LAYOUT THAT THE ╓╔├ CHIP SEES DATA. ╟EO╨AINT USES A FORMAT
IDENTICAL TO THE ╓╔├ CHIP LAYOUT ON SCREEN.
╟EO╨AINT PICTURES ARE STORED IN THE FOLLOWING FORMAT:
001 009 017 025 033 ..... 313
002 010 018 026 034 ..... 314
003 011 019 027 035 ..... 315
004 012 020 028 036 ..... 316
005 013 021 029 037 ..... 317
006 014 022 030 038 ..... 318
007 015 023 031 039 ..... 319
008 016 024 032 040 ..... 320
321 329 .....
322 330 .....
323 331 .....
324 332 .....
325 333 .....
326 334 .....
327 335 .....
328 336 .....
┴S YOU CAN SEE, THIS IS VERY DIFFERENT FROM THE ╨HOTO╙CRAP FORMAT. ├ONSECUTIVE
BYTES ARE ╬╧╘ STORED ON THE SCREEN BESIDE EACH OTHER. ╥ATHER, THEY ARE STORED
UNDERNEATH EACH OTHER INTO GROUPS OF 8 BYTES. ╘HIS MAKES MOVING THE DATA FROM
THE DISK ONTO THE SCREEN THAT MUCH FASTER, AS THE DECOMPACTED BYTES CAN JUST BE
STORED ON THE SCREEN AFTER EACH OTHER. ╧F COURSE, THIS MAKES PORTING ╟┼╧╙ PICS
TO THE 128'S ╓─├ THAT MUCH MORE DIFFICULT, AS THE ╓─├ CONFORMS TO THE
╨HOTO╙CRAP FORMAT.
├OMPRESSION ═ETHOD
------------------
╟┼╧╙ USES AN EXCELLENT COMPRESSION METHOD TO STORE FILES ON DISK. ┘OU MAY HAVE
NOTICED THAT NEARLY EMPTY PICTURES ON DISK CONSUME VERY LITTLE DISK SPACE. ╘HIS
CAN BE CREDITED TO ╟EO╨AINT'S SMART COMPRESSION TECHNIQUES.
┬ASICALLY, THE FORMAT OF THE COMPRESSION HAS ONE ├╧══┴╬─ BYTE FOLLOWED BY ONE
OR MORE ─┴╘┴ BYTES. ╘HE ├╧══┴╬─ BYTE TELLS ╟┼╧╙ WHAT TO DO WITH FOLLOWING ─┴╘┴
BYTES. ╘HERE ARE 4 COMMANDS FOR COMPRESSION:
1) ╔F THE ├╧══┴╬─ BYTE IS LESS THAN 64, THIS INDICATES THAT THERE ARE '├╧══┴╬─'
MANY ─┴╘┴ BYTES FOLLOWING THAT ARE TO BE TAKEN AS INDIVIDUAL BYTES. ╘HIS IS
THE LEAST EFFECTIVE METHOD OF COMPRESSION, AS NO COMPRESSION TAKES PLACE.
2) ╔F THE ├╧══┴╬─ BYTE RANGES FROM 65 TO 127, THEN THIS IS A SPECIAL TYPE OF
COMPRESSION. ╞IRST OF ALL, THE NEXT 8 BYTES IN THE FILE ARE READ IN AS ─┴╘┴.
╘HIS ─┴╘┴ IS USED TO MAKE AN 8*8 'STAMP'. ╙ECONDLY, THE AMOUNT OF TIMES TO
'STAMP' THIS 8*8 SQUARE IS CALCULATED (├╧══┴╬─ ┴╬─ 63). ╘HEN, THE STAMPING
IS DONE. '╙TAMPING' SOUNDS MORE DIFFICULT THAT IT REALLY IS. ╫HAT IT BOILS
DOWN TO, IS REPEATING THE 8 BYTE ─┴╘┴ STAMP '├╧══┴╬─ ┴╬─ 63'
TIMES.
3) ╔F THE ├╧══┴╬─ BYTE IS 129 OR GREATER, THEN THE FOLLOWING ─┴╘┴ BYTE IS
REPEATED '├╧══┴╬─ ┴╬─ 127' TIMES. ╘HIS IS DIFFERENT FROM #1, AS ONLY 1 ─┴╘┴
BYTE IS CALLED IN, AND SIMPLY REPEATED. #1 CALLED IN '├╧══┴╬─' MANY ─┴╘┴
BYTES.
4) ╔F THE ├╧══┴╬─ BYTE IS ┌┼╥╧, WE HAVE REACHED THE END OF THE ╓╠╔╥ RECORD FOR
THE ╟EO╨AINT PICTURE.
╔T SHOULD BE NOTED THAT THE ├╧══┴╬─ BYTE WILL ╬┼╓┼╥ BE 64 OR 128. ╔F IT IS,
THERE HAS BEEN AN ERROR.
╞ORMAT OF ─ATA ┴FTER ─ECOMPACTING
---------------------------------
┴FTER THE DATA HAS BEEN DECOMPACTED, IT REMAINS TO BE PLACED ON THE SCREEN. ┼ACH
╓╠╔╥ RECORD HOLDS 16 SCANLINES OF DATA, OR 2 CHARACTER LINES (DIFFERENT WAYS OF
LOOKING AT THE SAME THING).
╘HE FORMAT OF THE DATA IS AS FOLLOWS:
╞IRST, THERE IS 640 BYTES OF PICTURE DATA, COMPRISING THE FIRST CHARACTER
LINE (8 SCANLINES). ╥EMEMBER, ╟EO╨AINT PICTURES ARE 640 PIXELS ACROSS. 640
PIXELS WORKS OUT TO 80 BYTES. ┴ CHARACTER LINE IS 8 PIXELS DEEP, SO 80*8
COMES TO 640 BYTES.
╘HESE BYTES ARE FOLLOWED BY THE 640 BYTES FOR THE SECOND CHACACTER LINE
(NEXT 8 SCANLINES). ╘HIS IS FOLLOWED BY 8 GARBAGE BYTES THAT ACCIDENTALY
WORKED THEMSELVES INTO THE ORIGINAL ╟EO╨AINT DESIGN. ╘HEY SHOULD BE SET TO
ZERO.
╞INALLY, TWO SETS OF 80 BYTES OF COLOUR DATA FOLLOW. ╘HE FIRST SET
COMPRISES THE COLOUR FOR THE FIRST LINE, THE SECOND 80 BYTES FOR THE SECOND
LINE. ╘O WRAP THINGS UP, THE ╓╠╔╥ RECORD IS TERMINATED BY A ZERO BYTE.
╘HE NEXT ╓╠╔╥ RECORD WILL HOLD THE DATA FOR THE ╬┼╪╘ 16 SCANLINES, AND SO
ON.
├ONCLUSION
----------
╘HAT ABOUT WRAPS UP THIS DISCUSSION ON ╟EO╨AINT FORMAT FOR FILES. ╫E'VE
DISCUSSED THE FORMAT OF ╓╠╔╥ FILES ON DISK, LAYOUT OF PICTURE DATA ON SCREEN,
COMPRESSION METHODS USED IN ╟EO╨AINT FILES, AND THE FORMAT OF THE DATA ONCE
DECOMPACTED. ╔ HOPE THIS INFORMATION WILL COME IN HANDY FOR SOMEONE.
==============================================================================
╥ASTERS - ╫HAT ╘HEY ┴RE AND ╚OW TO ╒SE ╘HEM
BY ┬RUCE ╓RIELING - (BVRIELING@UNDERGRAD.MATH.WATERLOO.EDU)
┴NYONE WHO HAS FIDDLED AROUND WITH INTERRUPTS ON THE ├OMMODORE 64 HAS
UNDOUBTEDLY HEARD AT ONE TIME OR ANOTHER OF THE CONCEPT OF RASTERS BEING
MENTIONED. ╥ASTERS ARE THE 'ULTIMATE' ACHIEVEMENT OF INTERRUPT PROGRAMMING, OR
SO THEY SAY. ╫HAT IS A RASTER? ┴ND HOW DOES ONE GO ABOUT WRITING A PROGRAM TO
USE THEM?
╧VERVIEW OF WHAT ╔NTERRUPTS ARE ALL ABOUT
-----------------------------------------
┴ RASTER IS SORT FORM FOR THE CONCEPT OF A 'RASTER INTERRUPT'. ┬EFORE
GOING INTO RASTERS, PERHAPS A BRIEF REVIEW OF INTERRUPTS IS IN ORDER.
╔NTERRUPTS ARE EVENTS GENERATED BY THE ├╔┴ TIMER IN THE ├64 TO PERFORM CERTAIN
TASKS. 60 TIMES A SECOND, THE ├╔┴ CHIP SIGNALS AN INTERRUPT IS DUE TO BE
PROCESSED (IE. THE INTERRUPT TIMER TIMED OUT). ╘HIS CAUSES THE 6510 ├╨╒ TO STOP
EXECUTING THE CURRENT PROGRAM, SAVE THE REGISTERS ON THE STACK, AND BEGIN TO
EXECUTE THE INTERRUPT CODE. ╙OME OF THE THINGS WHICH GET DONE DURING AN
INTERRUPT INCLUDE THE KEYBOARD SCAN, AND UPDATING ╘╔ (THE SOFTWARE CLOCK). ╫HEN
THE INTERRUPT CODE IS FINISHED, AN ╥╘╔ INSTRUCTION IS EXECUTED, WHICH BRINGS
THE INTERRUPT'S EXECUTION TO A HALT. ╘HE REGISTERS ARE RETRIEVED FROM THE STACK,
AND THE CURRENT PROGRAM IN MEMORY CONTINUES TO EXECUTE ONCE AGAIN. ╔T WILL
CONTINUE TO DO SO UNTIL THE NEXT INTERRUPT OCCURS, ABOUT 1/60 OF A SECOND LATER.
╘HE ABOVE IS WHAT HAPPENS IN A NORMAL ├64 (THE ├128 FOLLOWS THE SAME IDEA, BUT
MORE EVENTS OCCUR DURING A ├128 INTERRUPT). [┼D. ╬OTE: ╔N ADDITION, THE ├=128
GENERATES ITS INTERRUPTS VIA A SCREEN RASTER INSTEAD OF THE ├╔┴ CHIP.]
╚OWEVER, YOU CAN CHANGE THE NORMAL COURSE OF EVENTS, AND CAUSE SOME CODE OF YOUR
DESIGN TO BE ADDED TO THE NORMAL LIST OF EVENTS WHICH OCCUR EVERY INTERRUPT.
╙OME OF THE SIMPLE FAVOURITES INCLUDE FLASHING THE BORDER 60 TIMES PER SECOND.
(╬OTE THAT WE HAVE NOT BEGUN THE TOPIC OF RASTERS YET; THIS HAS NOTHING TO DO
WITH RASTERS. ╘HAT DISCUSSION BEGINS AT THE NEXT HEADING.)
╚OW DO YOU CHANGE THE INTERRUPT'S NORMAL COURSE OF ACTION? ╔T'S RATHER SIMPLE.
╘HE ├64 CONTAINS AN INTERRUPT ╓┼├╘╧╥ AT LOCATIONS 788/9 WHICH IS 'JUMPED
THROUGH' BEFORE THE ╦ERNAL ╥OM GETS A CHANCE TO EXECUTE ITS CODE. ╔F YOU CHANGE
THIS VECTOR TO POINT TO ┘╧╒╥ CODE, AND MAKE THE END OF YOUR CODE POINT TO THE
NORMAL ╦ERNAL LOCATION (WHERE THE INTERRUPT NORMALLY WOULD HAVE JUMPED TO,
$┼┴31), AND YOU ARE CAREFUL NOT TO STEP ON ANYTHING, YOUR CODE WILL BE EXECUTED
60 TIMES PER SECOND.
┴N EXAMPLE IS IN ORDER:
; FLASHER
;
; THIS PROGRAM CAUSES THE BORDER TO FLASH 60 TIMES PER SECOND
;
SETUP = *
SEI ; DISABLE INTERRUPTS
LDA #<INTCODE ; GET LOW BYTE OF TARGET ROUTINE
STA 788 ; PUT INTO INTERRUPT VECTOR
LDA #>INTCODE ; DO THE SAME WITH THE HIGH BYTE
STA 789
CLI ; RE-ENABLE INTERRUPTS
RTS ; RETURN TO CALLER
INTCODE = *
INC $D020 ; CHANGE BORDER COLOUR
JMP $EA31 ; EXIT BACK TO ROM
╘HE ABOVE IS AN EXAMPLE OF A VERY SIMPLE INTERRUPT ROUTINE. ╔F YOU WERE TO
ASSEMBLE IT WITH AN ASSEMBLER, AND ╙┘╙ TO THE ╙┼╘╒╨ ROUTINE, YOU WOULD SEE YOUR
BORDER FLASH 60 TIMES PER SECOND.
┘OU WILL NOTICE THE ╙┼╔ AND ├╠╔ MACHINE LANGUAGE INSTRUCTIONS USED ABOVE. ╘HEY
ARE VERY IMPORTANT. ╫E DON'T WANT AN INTERRUPT OCCURRING IN BETWEEN THE ╙╘┴ 788
AND THE ╙╘┴ 789 INSTRUCTIONS.
╘HINK WHAT WOULD HAPPEN IF ONE DID: 788 WOULD HAVE BEEN MODIFIED, BUT 789 WOULD
STILL BE POINTING TO THE HIGH BYTE OF THE ╦ERNAL ADDRESS. ╥ESULT: THE INTERRUPT
WOULD HAVE JUMPED TO HEAVEN KNOWS WHERE. ┘OU CAN BE VIRTUALLY GUARANTEED THAT
IT WOULD ╬╧╘ BE POINTING TO A VALID PIECE OF INTERRUPT CODE. ┘OUR MACHINE WOULD
CRASH. ╘HE ╙┼╔ INSTRUCTION TURNS INTERRUPTS ╧╞╞, SO THAT THERE IS NO DANGER OF
AN INTERRUPT OCCURRING DURING EXECUTION OF THE FOLLOWING ROUTINE. ╘HE ├╠╔ TURNS
THEM BACK ON. ╔F YOU FORGET TO TURN THEM BACK ON, AND ACCIDENTALLY LEAVE THEM
OFF, YOUR KEYBOARD WILL FREEZE WHEN YOU RETURN TO BASIC, AND YOUR MACHINE WILL
SEEM TO LOCK UP.
╘HE ABOVE WAS A VERY SIMPLE EXAMPLE. ╘HERE ARE MANY USEFUL THINGS WHICH CAN ALSO
BE DONE ON AN INTERRUPT. ╔ HAVE SEEN CODE WHICH PLAYED MUSIC IN THE BACKGROUND
OF A RUNNING ┬ASIC PROGRAM (IT PLAYED THE POPULAR .═╒╙ FILES). ╟┼╧╙ USES
INTERRUPTS EXTENSIVELY TO CONTROL THE POINTING OF THE MOUSE, AND TO TRIGGER
EVENTS. ╔NTERRUPTS ARE POWERFUL BEASTS, AND THE FOLLOWING CONCEPT CONCERNING
RASTER INTERRUPTS SPECIFICALLY IS A PARTICULARLY USEFUL ANIMAL FOR SOME PEOPLE.
╘HE ╥ASTER
----------
┴ RASTER IS A LOOSELY USED TERM. ╔T REFERS TO AN INTERRUPT THAT IS TRIGGERED
WHEN THE RAY GUN ON THE BACK OF YOUR MONITOR DRAWS A CERTAIN LINE ON THE VIDEO
SCREEN. ╘HERE ARE MANY DIFFERENT SOURCES WHICH CAN CAUSE AN INTERRUPT. ┘OU ARE
NOT LIMITED TO WHAT THE ├╔┴ CHIP CAN DO. ╥ASTERS DEPEND ON INTERRUPTS
SPECIFICALLY GENERATED BY THE ╓╔─┼╧ CHIP. ┘OU COULD MAKE THIS INTERRUPT CHANGE
THE BORDER COLOUR OF THE SCREEN BELOW A CERTAIN SCREEN LINE. ╫HEN THE SCREEN
LINE YOU SPECIFIED GETS REDRAWN, THE INTERRUPT GOES OFF. ┘OUR CODE THEN QUICKLY
CHANGES SOME MEMORY LOCATIONS TO CREATE A DIFFERENT VIDEO MODE OR EFFECT. ┘OU
COULD CAUSE THE BOTTOM HALF OF THE SCREEN TO GETS IT'S CHARACTER DEFINITIONS
FROM ANOTHER, DIFFERENT CHARACTER SET. ╧R, YOU COULD MAKE THE TOP 3/4 OF YOUR
SCREEN EXIST IN HI-RES MULTI-COLOUR GRAPHICS, AND KEEP THE BOTTOM 1/4 OF THE
SCREEN IN TEXT MODE.
╙OME FACTS ABOUT THE VIDEO SCREEN: IT GETS REDRAWN EXACTLY 60 TIMES PER SECOND.
╔T CONTAINS 200 SCAN LINES ON THE NORMAL 25*40 DISPLAY, NUMBERED 50 TO 250 OR
THEREABOUTS (NOTE THAT THERE ARE MORE VISIBLE SCAN LINES THOUGH: THE TOP AND
BOTTOM BORDERS, FOR EXAMPLE). ╘HE ACTUAL RE-DRAWING OF THE SCREEN IS
SYNCHRONIZED TO THE ELECTRICAL POWER COMING INTO YOUR HOUSE, 60 ╚Z. ╘HAT'S WHY
SOME PROGRAMS BEHAVE DIFFERENTLY WHEN RUN ON ┼UROPEAN MACHINES. ╘HE POWER IS
DELIVERED AT 50 ╚Z OVER THERE.
╫HY DO WE HAVE TO WORRY ABOUT A VIDEO INTERRUPT? ╔F THE SCREEN GETS REDRAWN 60
TIMES PER SECOND, AND REGULAR INTERRUPTS ALSO OCCUR AT 60 TIMES PER SECOND, WHY
NOT SIMPLY PUT SOME CODE INTO THE REGULAR INTERRUPT TO DO WHAT WE WANT WITH THE
SCREEN? ┬ECAUSE THE TWO TYPES OF INTERRUPTS ARE NOT IN SYNC. ╬EITHER ONE OF THEM
OCCURS ┼╪┴├╘╠┘ 60 TIMES PER SECOND, AND THE DIFFERENCES ARE ENOUGH TO MAKE IT
NEXT TO IMPOSSIBLE TO GET COORDINATED ACTIVITY OF ANY KIND HAPPENING ON THE
SCREEN. ╫HEN WE USE THE VIDEO INTERRUPT, WE ╦╬╧╫ WE ARE AT A CERTAIN LINE ON THE
SCREEN, AS BEING ON THAT LINE IS WHAT CAUSED THE INTERRUPT TO HAPPEN IN THE
FIRST PLACE.
╙O, LET'S SUMMARIZE. ╫E KNOW THAT REGULAR INTERRUPTS OCCUR 60 TIMES PER SECOND.
╫E ALSO KNOW THAT THE VIDEO SCREEN GETS RE-DRAWN 60 TIMES PER SECOND, AND THAT
WE CAN CAUSE AN INTERRUPT TO BE GENERATED WHEN A CERTAIN LINE GETS DRAWN ON THE
SCREEN. ╧NE SLIGHT DRAWBACK TO ALL OF THIS IS THAT ┬╧╘╚ TYPES OF INTERRUPTS
(REGULAR AND RASTER DRIVEN) TRAVEL THROUGH THE ╙┴═┼ VECTOR (IE. ABOUT 120
INTERRUPTS PER SECOND, 60 OF ONE, AND 60 OF THE OTHER). ┘OUR CODE WILL HAVE TO
CHECK AND SEE WHAT THE SOURCE OF THE INTERRUPT WAS, AND ACT ACCORDINGLY. ╧R WILL
IT?
╘HE SYSTEM NEEDS AN INTERRUPT TO OCCUR 60 TIMES PER SECOND TO DO HOUSEKEEPING,
AND USES THE ├╔┴ CLOCK TO GENERATE THE INTERRUPTS. ╫E WANT TO INTERRUPT EVERY
TIME A CERTAIN SCAN LINE IS REACHED ON THE MONITOR, WHICH WILL ALSO JUST HAPPEN
TO OCCUR AT 60 TIMES PER SECOND. ╫E ALSO HAVE TO MAKE SURE THAT THEY DON'T
INTERFERE WITH EACH OTHER. ╘HE REGULAR INTERRUPTS SHOULD BE SENT TO THEIR ╥OM
DESTINATION, WHILE OUR VIDEO INTERRUPTS SHOULD GO TO OUR CODE, AND NO WHERE
ELSE.
╔F BOTH ARE OCCURRING AT 60 TIMES PER SECOND, WHY NOT DO THE JOB OF THE SYSTEM
╥OM, AND OUR VIDEO CODE ON THE ╙┴═┼ INTERRUPT? ╫E KNOW THAT THE ├╔┴ CHIP IS NOT
GOOD FOR THIS; IT IS OUT OF SYNC WITH THE VIDEO IMAGE. ╫HY NOT TURN ╧╞╞ THE ├╔┴
INTERRUPT, ENABLE THE RASTER/VIDEO INTERRUPT, AND DO BOTH JOBS ON ONE INTERRUPT?
╘HEN WE WOULD HAVE AN INTERRUPT SIGNAL THAT OCCURS 60 TIMES PER SECOND, AND IS
IN PERFECT SYNC WITH THE VIDEO IMAGE.
╘HAT'S EXACTLY WHAT WE'RE GOING TO DO.
┴STUTE READS WILL NOTICE A SLIGHT FLAW IN THE ABOVE LOGIC. ╞OR SIMPLIFICATION
PURPOSES, ╔ DIDN'T GET INTO THE FACT THAT YOU WILL NEED ╘╫╧ RASTER INTERRUPTS
╨┼╥ ╙├╥┼┼╬ TO ACCOMPLISH ANYTHING USEFUL. ╫HY TWO? ┬ECAUSE ANY CHANGE TO THE
VIDEO MODE YOU PUT INTO EFFECT 3/4 OF THE WAY DOWN THE SCREEN WILL HAVE TO BE
UNDONE AT THE ╘╧╨ OF THE NEXT SCREEN UPDATE. ╔F YOU DECIDE TO MAKE THE TOP 3/4
OF THE SCREEN A HI-RES IMAGE, AND THE BOTTOM 1/4 TEXT, YOU NEED ONE INTERRUPT
3/4 OF THE WAY DOWN THE SCREEN TO CHANGE FROM HI-RES TO TEXT, BUT YOU NEED A
╙┼├╧╬─ ONE AT THE TOP OF THE SCREEN TO CHANGE BACK TO HI-RES FROM TEXT.
╙O, WE WILL NOW HAVE 120 INTERRUPTS GOING OFF EVERY SECOND TO ACCOMPLISH OUR
VIDEO DESIRES, WITH 60 OF THEM WORKING A DOUBLE SHIFT, MAKING SURE THE SYSTEM
INTERRUPT CODE GETS EXECUTED ALSO. ╥EMEMBER THAT WE ARE WORKING WITH A SPECIFIC
EXAMPLE. ╘HERE IS NO REASON WHY YOU COULDN'T SPLIT THE SCREEN INTO ╬ DIFFERENT
VIDEO MODES, AND HAVE (╬+1)*60 INTERRUPTS GOING OFF PER SECOND. ┴S LONG AS YOU
KEEP YOUR CODE SHORT (SO YOUR INTERRUPTS DON'T TAKE TOO LONG, AND HAVE ANOTHER
INTERRUPT OCCUR BEFORE THE CURRENT ONE IS DONE - MESSY), IT WILL WORK
BEAUTIFULLY.
╙O FAR, THIS IS ALL TALK. ╠ET'S WRITE A FEW SHORT CODE SEGMENTS TO ACCOMPLISH
SOME OF THE FEATS WE'VE JUST DISCUSSED.
╘HE FIRST WE'LL DO IS A RE-HASH OF THE ONE PRESENTED ABOVE. ╔T FLASHES THE
BORDER AGAIN. ╔T DOES NOT DO ANY MID-SCREEN CHANGES OF VIDEO MODES OR ANYTHING
FANCY LIKE THAT, SO ONLY 1 INTERRUPT PER SCREEN IS REQUIRED (IE. 60 PER SECOND,
NOT 120 ETC.). ╘HIS PROGRAM SIMPLY SHOWS THE SAME IDEA, BUT THIS TIME USING
VIDEO INTERRUPTS AS THE SOURCE RATHER THAN THE ├╔┴. ┘OU PROBABLY WON'T
NOTICE A DIFFERENCE DURING EXECUTION.
----------------------------------------------------------------------------
; FLASHER - PART ╔╔
;
; THIS PROGRAM CAUSES THE BORDER TO FLASH 60 TIMES PER SECOND
; THE SOURCE OF THE INTERRUPTS IS THE VIDEO CHIP
;
SETUP = *
SEI ; DISABLE INTERRUPTS
LDA #$7F ; TURN OFF THE CIA INTERRUPTS
STA $DC0D
LDA $D01A ; ENABLE RASTER IRQ
ORA #$01
STA $D01A
LDA $D011 ; CLEAR HIGH BIT OF RASTER LINE
AND #$7F
STA $D011
LDA #100 ; LINE NUMBER TO GO OFF AT
STA $D012 ; LOW BYTE OF RASTER LINE
LDA #>INTCODE ; GET LOW BYTE OF TARGET ROUTINE
STA 788 ; PUT INTO INTERRUPT VECTOR
LDA #<INTCODE ; DO THE SAME WITH THE HIGH BYTE
STA 789
CLI ; RE-ENABLE INTERRUPTS
RTS ; RETURN TO CALLER
INTCODE = *
INC $D020 ; CHANGE BORDER COLOUR
LDA $D019 ; CLEAR SOURCE OF INTERRUPTS
STA $D019
LDA #100 ; RESET LINE NUMBER TO GO OFF AT
STA $D012
JMP $EA31 ; EXIT BACK TO ROM
--------------------------------------------------------------------------
┴S YOU CAN TELL, THERE'S A WEE BIT MORE TO THIS CODE THAN THERE WAS IN THE
ORIGINAL. ┼XECUTE IT, AND YOU'LL NOTICE THAT IT LOOKS PRETTY MUCH THE SAME AS
THE RESULTS FROM THE FIRST PROGRAM. ┬UT THERE'S A DIFFERENCE: THE INTERRUPTS
ARE NOW BEING GENERATED FROM THE VIDEO CHIP, NOT THE ├╔┴. ╞OR THIS PROGRAM, IT
DIDN'T MAKE MUCH DIFFERENCE. ╚OWEVER, FOR A MORE COMPLICATED PROGRAM, IT MAKES
A WORLD OF DIFFERENCE.
╔'D BETTER EXPLAIN SOME OF THE CODE USED ABOVE:
LDA #$7F
STA $DC0D
- ╘HIS PIECE DISABLES ANY INTERRUPTS CAUSED BY THE ├╔┴ CHIP.
LDA $D01A
ORA #$01
STA $D01A
- ╠OCATION $D01A CONTROLS WHICH SOURCES MAY CAUSE AN INTERRUPT
(OTHER THAN THE NORMAL ├╔┴). ╘HERE ARE 4 DIFFERENT POSSIBLE
SOURCES: RASTERS, SPRITE TO SPRITE COLLISION, SPRITE TO
BACKGROUND COLLISION, AND THE LIGHT PEN. ┬IT #0 IS THE RASTER
BIT, AND THIS PIECE OF CODE ACTIVATES IT.
LDA $D011
AND #$7F
STA $D011
- ╘HIS CODE CLEARS BIT #7 OF LOCATION $D011. ╘HIS LOCATION IS USED
FOR MANY DIFFERENT THINGS. ┬IT #7 REPRESENTS THE HIGHEST BIT OF
THE RASTER LINE (SEE SEGMENT BELOW FOR MORE ON THE RASTER LINE
#). ═ORE THAN 256 RASTER LINE NUMBERS ARE POSSIBLE (SOME ARE OFF
SCREEN, AND SOME REPRESENT THE UPPER AND LOWER BORDER AREAS).
╘HIS BIT IS THE 9TH BIT. ╔ SET IT TO ZERO BECAUSE ALL MY CODE
AFFECTS RASTERS ONLY ON THE NORMAL 25*40 LINE DISPLAY, WELL
WITHIN THE 0-255 RANGE. ╘HIS DECISION WAS AN ARBITRARY CHOICE ON
MY PART, TO MAKE THE CODE SIMPLER.
LDA #100
STA $D012
- ╠OCATION $D012 IS THE LOWER 8 BITS OF THE RASTER LINE ON WHICH
THE INTERRUPT IS TO BE GENERATED. ╘HE NUMBER 100 WAS ANOTHER
ARBITRARY CHOICE. ╞OR CHANGING BORDER COLOURS, THE ACTUAL LINE
NUMBER WAS NOT IMPORTANT. ╠ATER ON, IN THE NEXT EXAMPLE, IT WILL
BECOME IMPORTANT.
LDA #>INTCODE
...
RTS
- ╥E-VECTORS THE INTERRUPT CODE TO THE NEW CODE.
INC $D020
- ├HANGES THE BORDER COLOUR.
LDA $D019
STA $D019
- ╘HESE LINES CLEAR THE BIT IN THE INTERRUPT REGISTER WHICH TELLS THE
SOURCE OF THE INTERRUPT (IN PREPERATION FOR THE NEXT).
LDA #100
STA $D012
- ╘HIS LINE RESETS THE RASTER LINE TO GO OFF AT LINE NUMBER 100
AGAIN (SAME AS ABOVE). ╔T SHOULD BE RESET, SO THE NEXT INTERRUPT
WILL KNOW WHAT LINE TO OCCUR ON.
JMP $EA31
- ┼XIT BACK TO THE ╦ERNAL ╥OM.
┴ ╒SEFUL ┼XAMPLE
----------------
╘HE FOLLOWING IS AN EXAMPLE OF A MORE SOPHISTICATED PIECE OF RASTER CODE. ╔T
MAKES THE TOP HALF OF THE SCREEN BORDER WHITE, AND THE BOTTOM HALF BLACK.
---------------------------------------------------------------------------
SETUP = *
; SOME EQUATES
├╧╠╧╒╥1 = 0
├╧╠╧╒╥2 = 1
╠╔╬┼1 = 20
╠╔╬┼2 = 150
; CODE STARTS
SETUP = *
SEI ; DISABLE INTERRUPTS
LDA #$7F ; TURN OFF THE CIA INTERRUPTS
STA $DC0D
LDA $D01A ; ENABLE RASTER IRQ
ORA #$01
STA $D01A
LDA $D011 ; CLEAR HIGH BIT OF RASTER LINE
AND #$7F
STA $D011
LDA #╠╔╬┼1 ; LINE NUMBER TO GO OFF AT
STA $D012 ; LOW BYTE OF RASTER LINE
LDA #>INTCODE ; GET LOW BYTE OF TARGET ROUTINE
STA 788 ; PUT INTO INTERRUPT VECTOR
LDA #<INTCODE ; DO THE SAME WITH THE HIGH BYTE
STA 789
CLI ; RE-ENABLE INTERRUPTS
RTS ; RETURN TO CALLER
INTCODE = *
LDA MODEFLAG ; DETERMINE WHETHER TO DO TOP OR
; BOTTOM OF SCREEN
BEQ MODE1
JMP MODE2
MODE1 = *
LDA #$01 ; INVERT MODEFLAG
STA MODEFLAG
LDA #├╧╠╧╒╥1 ; SET OUR COLOUR
STA $D020
LDA #╠╔╬┼1 ; SETUP LINE FOR ╬┼╪╘ INTERRUPT
STA $D012 ; (WHICH WILL ACTIVATE ═╧─┼2)
LDA $D019
STA $D019
JMP $EA31 ; ═╧─┼1 EXITS TO ╥OM
MODE2 = *
LDA #$00 ; INVERT MODEFLAG
STA MODEFLAG
LDA #├╧╠╧╒╥2 ; SET OUR COLOUR
STA $D020
LDA #╠╔╬┼2 ; SETUP LINE FOR ╬┼╪╘ INTERRUPT
STA $D012 ; (WHICH WILL ACTIVATE ═╧─┼1)
LDA $D019
STA $D019
PLA ; WE EXIT INTERRUPT ENTIRELY.
TAY ; SINCE HAPPENING 120 TIMES PER
PLA ; SECOND, ONLY 60 NEED TO GO TO
TAX ; HARDWARE ╥OM. ╘HE OTHER 60 SIMPLY
PLA ; END
RTI
MODEFLAG .BYTE 0
----------------------------------------------------------------------------
╘HE ABOVE CODE, WHEN EXECUTED, WILL RESULT IN THE TOP HALF OF YOUR BORDER BEING
WHITE, AND THE BOTTOM BLACK. ┘OU MAY WISH TO FIDDLE WITH THE EQUATES (├╧╠╧╒╥1,
├╧╠╧╒╥2, ╠╔╬┼1, AND ╠╔╬┼2) TO GET DIFFERENT EFFECTS.
╔ SEE SOME CONFUSED FACES CONCERNING WHY THE ABOVE EXIT THE INTERRUPTS THE WAY
THEY DO. ╥EMEMBER, SINCE WE WANT A SPLIT SCREEN EFFECT, WE HAVE TO HAVE ONE
INTERRUPT OCCUR AT THE ╘╧╨ OF THE SCREEN, TO TURN ON THE ╫╚╔╘┼ EFFECT, AND ONE
MIDWAY DOWN TO TURN ON THE ┬╠┴├╦ EFFECT. ╘WO INTERRUPTS TIMES 60 MEANS 120
INTERRUPTS WILL BE EXECUTED PER SECOND. ╘HE ╥OM ONLY NEEDS 60 PER SECOND TO
SERVICE THE KEYBOARD AND ITS OTHER STUFF. ╙O, WE SEND 60 TO THE ╥OM (THE
INTERRUPTS WHICH GO THROUGH ═╧─┼1) BY ╩═╨ING TO $┼┴31, AND THE OTHER 60 WE
TRASH. ╘HE ╨╠┴... ╥╘╔ BUSINESS IS THE PROPER WAY TO BRING AN INTERRUPT TO AN END
WITHOUT GOING THROUGH THE ╥OM. ╘HE ╥╘╔ WILL ╥E╘URN FROM ╔NTERRUPT, AND CAUSE THE
REGULAR PROGRAM TO CONTINUE TO EXECUTE.
╘HAT BRINGS TO AN END THIS DISCUSSION ON RASTERS. ╔ HOPE THE ABOVE EXAMPLES
HAVE PROVED TO BE A VALUABLE LEARNING TOOL FOR YOU. ╫ITH LUCK, THEY WILL
MOTIVATE YOU TO CONTINUE TO EXPERIMENT WITH RASTERS, AND COME UP WITH SOME NEAT
EFFECTS.
╔F YOU HAVE ANY QUESTIONS, BE SURE TO ASK ME ABOUT THEM.
==============================================================================
┬╒╥╙╘╔╬╟ ┘╧╒╥ 128: ╘╚┼ ╞┴╙╘╠╧┴─ ┬╒╥╙╘ ├╧══┴╬─
BY ├RAIG ┬RUCE <F2RX@JUPITER.SUN.CSD.UNB.CA>
1. ╔╬╘╥╧─╒├╘╔╧╬
╘HIS ARTICLE DISCUSSES THE WELL-UNKNOWN ╞ASTLOAD COMMAND OF THE 1571 AND 1581
DISK DRIVE ┬URST ├OMMAND ╔NSTRUCTION ╙ET. ╔F YOU LOOK IN THE BACK OF YOUR '71
(OR '81 ╔ PRESUME) DISK DRIVE MANUAL, YOU WILL FIND THAT THE INFORMATION GIVEN
ABOUT THE ╞ASTLOAD UTILITY IS NOT EXACTLY ABUNDANT.
╘HE ╞ASTLOAD COMMAND WAS INTENDED TO LOAD PROGRAM FILES INTO MEMORY FOR
EXECUTION, BUT IT CAN BE USED JUST AS WELL FOR READING THROUGH SEQUENTIAL
FILES THAT WOULD BE MUCH TOO LARGE TO LOAD INTO A SINGLE BANK OF INTERNAL
MEMORY.
╘O MAKE USE OF THE ╞ASTLOAD BURST COMMAND, ╔ IMPLEMENT A WORD COUNTING UTILITY
THAT WILL COUNT THE NUMBER OF LINES, WORDS, AND CHARACTERS IN A TEXT FILE ON A
1571 OR 1581 DISK DRIVE. ╘HE ADVANTAGE OF USING THE ╞ASTLOAD COMMAND OVER
REGULAR SEQUENTIAL FILE ACCESSING THROUGH THE KERNEL AND ─╧╙ IS THAT THE
╞ASTLOAD OPERATES ABOUT 3.5 TIMES FASTER ON BOTH DRIVES.
2. ╫╧╥─ ├╧╒╬╘╔╬╟ ╒╘╔╠╔╘┘
╘O USE THE WORD COUNTING PROGRAM, ╠╧┴─ AND ╥╒╬ IT LIKE A REGULAR ┬┴╙╔├
PROGRAM. ╔T WILL ASK YOU FOR THE NAME OF A FILE. ┼NTER THE NAME IF IT IS ON
DEVICE NUMBER 8, OR PUT A ONE CHARACTER PREFIX AND A ":" IF IT IS ON ANOTHER
DEVICE. ┴ "B" MEANS DEVICE 9, "C" DEVICE 10, ETC. ╘HE FOLLOWING ARE EXAMPLES
OF VALID NAMES:
. FILENAME "FILENAME" ON DEVICE 8
. B:FILENAME "FILENAME" ON DEVICE 9
. A:FILENAME "FILENAME" ON DEVICE 8
╘HE FILE MUST BE ON EITHER A 1571 OR 1581 DISK DRIVE; THE PROGRAM WILL NOT
WORK WITH NON-BURST DEVICES. ╘HE PROGRAM WILL WORK WITH EITHER ╨╥╟ OR ╙┼╤
FILES, SINCE THE ╞ASTLOAD COMMAND CAN BE TOLD NOT TO WORRY ABOUT THE FILE
TYPE.
╔ USE THE SAME DEFINITION OF A WORD AS THE ╒NIX "WC" COMMAND USES: A SEQUENCE
OF CHARACTERS DELIMITED BY WHITESPACE, WHERE WHITESPACE IS DEFINED TO BE
╙╨┴├┼, ╘┴┬, AND ╬┼╫╠╔╬┼ (├ARRIAGE ╥ETURN) CHARACTERS. ╘O GET THE LINE COUNT,
╔ SIMPLY COUNT THE NUMBER OF ╬┼╫╠╔╬┼S. ╔F THE LAST LINE OF THE FILE DOES NOT
END WITH A ╬┼╫╠╔╬┼ CHARACTER, THEN THE COUNT WILL BE ONE LINE SHORT. ╘HIS IS
THE SAME AS THE ╒NIX WC COMMAND TOO. ┴ PROPER TEXT FILE SHOULD HAVE ITS LAST
LINE END WITH A ╬┼╫╠╔╬┼ CHARACTER.
╧N MY ╩IFFY─╧╙-IFIED 1571 AND 1581, ╔ AM ABLE TO ACHIEVE A WORD COUNTING SPEED
OF 5,400 CHARS/SEC AND 6,670 CHARS/SEC, RESPECTIVELY. ╔ AM NOT SURE HOW MUCH
OF A DIFFERENCE ╩IFFY─╧╙ MAKES, BUT ╔ AM NOT WILLING TO RIP OUT THE ╥╧═S TO
CHECK. ╔ TESTED USING A 318╦ FILE.
3. ┬╒╥╙╘ ╥┼┴─ ╠╔┬╥┴╥┘
╘HIS SECTION PRESENTS THE BURST READING LIBRARY THAT YOU CAN INCORPORATE INTO
YOUR OWN PROGRAMS AND DESCRIBES HOW THE BURST COMMANDS WORK. ╘HE LIBRARY HAS
THREE CALLS:
. BURST╧PEN ( .┴=─EVICE, .╪=╬AME╠EN, BURST┬UF=╞ILENAME ) : <FIRST BLOCK>
. BURST╥EAD () : BURST┬UF, BURST╙TATUS, BURST┬UF├OUNT
. BURST├LOSE ()
╔ DEFINE THREE COMMON STORAGE VARIABLES FOR USING THIS PACKAGE: "BURST┬UF",
"BURST╙TATUS", AND "BURST┬UF├OUNT". "BURST┬UF" IS A 256 BYTE AREA WHERE THE
DATA READ IN FROM THE DISK DRIVE IS STORED BEFORE PROCESSING, AND IS LOCATED
AT $0┬00. "BURST╙TATUS" IS A ZERO-PAGE LOCATION THAT KEEPS THE STATUS
RETURNED FROM THE BURST COMMAND SYSTEM. ╘HIS IS NEEDED BY THE USER TO DETECT
WHEN THE END OF FILE HAS BEEN ENCOUNTERED. "BURST┬UF├OUNT" GIVES THE NUMBER
OF DATA BYTES AVAILABLE IN "BURST┬UF" AFTER AN OPEN OR READ OPERATION. ╔TS
VALUE WILL BE SOMEWHERE BETWEEN 1 AND 254. ┴ FULL SECTOR CONTAINS 254 BYTES
OF DATA AND TWO BYTES OF CONTROL INFORMATION.
"BURST╙TATUS" AND "BURST┬UF├OUNT" ARE DEFINED TO BE AT LOCATIONS $╞┼ AND $╞╞,
RESPECTIVELY. ┘OU ARE ALLOWED TO ALTER THE VALUES OF THE TWO VARIABLES AND
THE DATA BUFFER BETWEEN CALLS, IF YOU WISH. ╞OR REASONS NOT COMPLETELY
UNDERSTOOD, INTERRUPTS MUST BE DISABLED FOR THE ENTIRE COURSE OF BURST READING
A FILE. ╔ SUSPECT THIS IS BECAUSE THE ╔╥╤ SERVICE ROUTINE READS THE INTERRUPT
MASK REGISTER OF ├╔┴#1, THUS CLEARING THE ╙ERIAL─ATA╥EADY FLAG THAT THE BURST
READ ROUTINE WAITS FOR. ┴NYWAY, THE OPEN ROUTINE DOES A ╙┼╔ AND THE CLOSE
ROUTINE DOES A ├╠╔, SO YOU DON'T HAVE TO DO THIS YOURSELF.
╔F AN ERROR OCCURS DURING THE EXECTION OF ONE OF THESE ROUTINES, IT WILL
RETURN WITH THE CARRY FLAG SET AND WITH THE ERROR CODE IN THE .┴ REGISTER
(SAME AS THE KERNEL (YES, ╔ KNOW THAT ├OMMODORE LIKES TO CALL IT THE
"KERN┴L")). ┼RROR CODES 0 TO 9 CORRESPOND TO THE STANDARD KERNEL CODES, ERROR
CODE 10 MEANS THAT THE DEVICE IS NOT A BURST DEVICE, AND ERROR CODES 16 TO 31
CORRESPOND TO THE BURST CONTROLLER STATUS CODES 0-15. ╔F NO ERROR OCCURS, THE
ROUTINES RETURN WITH THE CARRY FLAG CLEAR, OF COURSE.
╧NLY ONE FILE MAY BE OPEN AT A TIME FOR ╞ASTLOADING, SINCE ╞ASTLOAD TAKES OVER
THE DISK DRIVE AND THE ENTIRE SERIAL BUS. ┼VEN REGULAR FILES CANNOT BE
ACCESSED WHILE A FASTLOAD IS IN PROGRESS. ╘HUS, ╞ASTLOAD IS NOT SUITABLE FOR
ALL FILE PROCESSING APPLICATIONS, BUT IT WORKS VERY WELL FOR READING A FILE
INTO MEMORY (LIKE FOR A TEXT EDITOR) AND FOR SUMMARIZATION OPERATIONS (LIKE
WORD COUNTING). ╘HE BURST LIBRARY REQUIRES THAT THE KERNEL AND ╔/╧ SPACE BE
IN CONTEXT WHEN IT IS CALLED.
3.1. ┬╒╥╙╘ ╧╨┼╬
╘HE WAY THAT A BURST COMMAND IS GIVEN IS TO GIVE A MAGICAL INCANTATION OVER
THE COMMAND CHANNEL TO THE DISK DRIVE. ┘OU CAN EITHER USE THE LOW-LEVEL
SERIAL BUS CALLS (╠╔╙╘╬, ╙┼├╬─, ├╔╧╒╘, AND ╒╬╠╙╬) OR USE THE ╧╨┼╬ AND ├╚╥╧╒╘
CALLS. ╔ USED THE LOW LEVEL CALLS FOR A LITTLE EXTRA ZIP.
╘HE BURST COMMAND FORMAT FOR ╞ASTLOAD IS GIVEN IN THE BACK OF YOUR DRIVE
MANUAL:
. ┬┘╘┼ \ BIT: 7 6 5 4 3 2 1 0 ▄ ╓ALUE
. -------+--------+-----+-----+-----+-----+-----+-----+-----+-------
. 0 ▄ 0 ▄ 1 ▄ 0 ▄ 1 ▄ 0 ▄ 1 ▄ 0 ▄ 1 ▄ "╒"
. 1 ▄ 0 ▄ 0 ▄ 1 ▄ 1 ▄ 0 ▄ 0 ▄ 0 ▄ 0 ▄ "0"
. 2 ▄ ╨ ▄ ╪ ▄ ╪ ▄ 1 ▄ 1 ▄ 1 ▄ 1 ▄ 1 ▄ 159
. 3 - ?? ▄ <FILENAME> ▄
. -------+--------------------------------------------------+-------
WHERE "╪" MEANS "DON'T CASE" AND "╨" MEANS "PROGRAM". ╔F THE ╨ BIT IS '0'
THEN ONLY PROGRAM (╨╥╟) FILES CAN BE LOADED, AND IF IT IS '1' THEN SEQUENTIAL
(╙┼╤) FILES CAN BE LOADED AS WELL. ╘HE PACKAGE AUTOMATICALLY SETS THIS FLAG
FOR YOU. ╬OTE THAT YOU DON'T HAVE TO DO AN ╔NQUIRE ─ISK OR ╤UERY ─ISK ╞ORMAT
IN ORDER TO USE THIS COMMAND LIKE YOU HAVE TO DO WITH THE BLOCK READING AND
WRITING COMMANDS.
╔F YOU WANT TO TRY GIVING THE INCANTATION YOURSELF, ENTER:
╧╨┼╬1,8,15,"╒0"+├╚╥$(159)+"╞╔╠┼╬┴═┼"
(WHERE "╞╔╠┼╬┴═┼" IS THE NAME OF SOME FILE THAT EXISTS ON YOUR DISK) ON YOUR
128 AND YOUR DISK DRIVE WILL SPRING TO LIFE AND WAIT FOR YOU TO READ THE FILE
DATA. ┘OU CAN'T READ THE DATA FROM ┬┴╙╔├, SO TO CANCEL THE COMMAND:
├╠╧╙┼1
╘HE "BURST╧PEN" CALL OF THIS PACKAGE ACCEPTS THE NAME OF THE FILE TO BE LOADED
AT THE START OF THE "BURST┬UF" BUFFER, THE LENGTH OF THE FILENAME IN THE .╪
REGISTER, AND THE DEVICE NUMBER TO LOAD THE FILE FROM IN THE .┴ REGISTER. ╘HE
BURST COMMAND HEADER AND THE FILENAME ARE SENT TO THE DISK DRIVE AS DESCRIBED
ABOVE.
╘HE OPEN COMMAND ALSO READS THE FIRST SECTOR OF THE FILE, FOR TWO REASONS.
╞IRST, THE STATUS BYTE RETURNED FOR THE FIRST SECTOR HAS SPECIAL MEANING.
╙TATUS CODE $02 MEANS "FILE NOT FOUND". ╘HE PACKAGE TRANSLATES THIS INTO THE
KERNEL ERROR CODE. ╙ECOND, AND MOST IMPORTANT, THERE IS A BIZARRE FEATURE
(READ: "BUG") IN THE ╞ASTLOAD COMMAND. ╔F THE FILE TO BE READ IS ONLY ONE
BLOCK LONG, THEN THE NUMBER OF BYTES REPORTED FOR THE BLOCK LENGTH IS TWO
BYTES TOO SHORT. ╘HE FOLLOWING TABLE GIVES THE NUMBER OF BYTES REPORTED AND
THE NUMBER OF ACTUAL BYTES IN THE SECTOR:
. ┴CTUAL ▄ 4 ▄ 3 ▄ 2 ▄ 1 ▄ 0 ▄
. ---------+---------+---------+---------+---------+---------+
. ╥EPORTED ▄ 2 ▄ 1 ▄ 0 ▄ 255 ▄ 255 ▄
╘HIS IS WHERE ╔ RAN INTO PROBLEMS WITH ┌ED-128; THE LOGIC OF MY PROGRAM
SCREWED UP ON A ZERO LENGTH. ╔ HAVE CORRECTED THE PROBLEM HERE, THOUGH. ╘HIS
BUG IS BIZARRE BECAUSE IT ONLY HAPPENS IF THE FIRST SECTOR IS THE ONLY SECTOR
IN THE FILE. ╘HE REPORTED LENGTH FOR ALL SUBSEQUENT SECTORS IS CORRECT. ╬OTE
ALSO THAT 255 IS REPORTED FOR LENGTHS OF BOTH 1 AND 0. ╘HIS IS BECAUSE THERE
IS NO ACTUAL ZERO LENGTH FOR ├OMMODORE FILES. ╔F YOU ╧╨┼╬1,8,2,"┼═╨╘┘" AND
THEN IMMEDIATELY ├╠╧╙┼1 YOU GET A FILE WITH ONE CARRIAGE RETURN CHARACTER IN
IT.
╘HE OPEN ROUTINE CALLS THE READ ROUTINE TO READ A SECTOR AND IF IT WAS THE
ONLY SECTOR OF THE FILE, THE TWO ADDITIONAL BYTES ARE BURST-READ AND PUT INTO
THE DATA BUFFER. ╬OTE THAT INCREMENTING THE REPORTED COUNT OF 255 TWICE GIVES
THE CORRECT COUNT OF 1. ┴LSO INTERESTING IN THIS CASE IS THAT WHEN THE
1571/81 REPORTS THE 255, IT ACTUALLY TRANSFERS 255 BYTES OF DATA, ALL OF WHICH
ARE BOGUS. ╔T SEEMS TO ME THAT THEY MADE THE 1581 BUG-COMPATIBLE WITH THE
1571 IN THIS RESPECT.
╘HE OPEN ROUTINE ALSO EXECUTES A ╙┼╔ FOR REASONS DISCUSSED ABOVE. ╘HE
INFORMATION RETURNED BY THE OPEN CALL IS THE SAME AS WHAT IS RETURNED FOR THE
"BURST╥EAD" CALL DISCUSSED NEXT.
3.2. ┬╒╥╙╘ ╥┼┴─
╧NCE THE ╞ASTLOAD COMMAND IS STARTED, THE DRIVE STARTS WAITING TO TRANSFER THE
DATA TO YOU. ╘HE TRANSFER OCCURS SECTOR BY SECTOR, WITH EACH SECTOR PRECEEDED
BY A BURST STATUS BYTE. ╘HE DATA IS TRANSFERRED USING THE SHIFT REGISTER OF
├╔┴#1 AND THE HANDSHAKING IS DONE USING THE ╙LOW ╙ERIAL ├LOCK LINE OF ├╔┴#2.
╘O RECEIVE A BYTE, YOU TOGGLE THE ╙LOW ╙ERIAL ├LOCK LINE AND WAIT FOR THE
╙HIFT ╥EGISTER ╥EADY SIGNAL FROM ├╔┴#1 AND THEN READ THE DATA VALUE FROM THE
SHIFT DATA REGISTER.
╧NE OF THE CLOCK REGISTERS IN THE ├╔┴ IN THE 1571/81 IS USED AS THE BAUD RATE
GENERATOR FOR THE SERIAL LINE. ╔ THINK THAT IT USES A DELAY OF 4 MICROSECONDS
PER BIT, WHICH GIVES A BAUD RATE OF 250,000 (31.25╦/SEC). ╔N MY
EXPERIMENTATION, THE MAXIMUM BAUD RATE ╔ HAVE EVER ACHIEVED IN REALITY IS
200,000 (25╦/SEC). ╔ READ IN MY 1571 ╔NTERNALS BOOK THAT THE 250,000 BAUD
RATE CANNOT ACTUALLY BE ACHIEVED BECAUSE OF ELECTRICAL PROBLEMS THAT ╔ DON'T
UNDERSTAND. ╘HIS IS AN IMPORTANT DIFFERENCE BECAUSE THE DATA COMES FLYING OFF
THE SURFACE OF THE DISK AT AROUND 30╦/SEC AND IF THE SERIAL BUS WERE FAST
ENOUGH, IT COULD BE TRANSFERRED TO THE COMPUTER AS IT IS BEING READ. ╙OME
THINGS WOULD BE SO MUCH MORE CONVENIENT IF WHOMEVER CREATED THE UNIVERSE HAD
THOUGHT TO MAKE LIGHT GO JUST A LITTLE BIT FASTER.
╘HE BURST HANDSHAKING PROTOCOL SLOWS THE MAXIMUM TRANSFER RATE DOWN TO ABOUT
16╦/SEC. ╧F COURSE, THE DISK DRIVE HAS MORE THINGS TO KEEP ON TOP OF THAN
JUST TRANSFERRING DATA, SO THE ACTUAL BURST THROUGHPUT IS LOWER THAN THAT:
ABOUT 5.4╦/SEC WITH MY ╩IFFY─╧╙-IFIED 1571 AND ABOUT 7╦/SEC WITH A 1581. ╬OTE
THAT YOU CAN PROBABLY INCREASE YOUR 1571'S BURST PERFORMANCE A BIT BY SETTING
IT TO USE A SECTOR INTERLEAVE FACTOR OF 4, USING THE "╒0>╙"+├╚╥$(I) BURST
COMMAND. ┬Y DEFAULT, A 1571 WRITES FILES WITH AN INTERLEAVE OF 6.
┴LL OF THE SECTORS BEFORE THE LAST ONE WILL CONTAIN 254 BYTES OF DATA AND THE
LAST ONE WILL CONTAIN A SPECIFIED NUMBER OF BYTES, FROM 1 TO 254. ╘HE STATUS
CODE RETURNED FOR THE LAST SECTOR IS VALUE $1╞. ╔N THIS CASE, AN ADDITIONAL
BYTE IS SENT BEFORE THE DATA BYTES THAT TELLS HOW MANY DATA BYTES THERE WILL
BE. ╘HIS IS THE VALUE THAT IS BUGGED FOR ONE-SECTOR FILES AS DESCRIBED IN THE
LAST SECTION. ╞OR THOSE WHO LIKE PICTURES, HERE ARE DIAGRAMS OF THE DATA
TRANSFERRED FOR A SECTOR:
. ╥┼╟╒╠┴╥ ╙┼├╘╧╥ ╠┴╙╘ ╙┼├╘╧╥ ╧╞ ╞╔╠┼
. +-------------------+ +--------------------+
. 0 ▄ ┬URST ╙TATUS ┬YTE ▄ 0 ▄ ┬URST ╙TATUS = $1╞ ▄
. +-------------------+ +--------------------+
. 1 ▄ ▄ 1 ▄ ┬YTE ├OUNT = ╬ ▄
. ... + 254 ─ATA ┬YTES ▄ +--------------------+
. 254 ▄ ▄ 2 ▄ ▄
. +-------------------+ ... ▄ ╬ ─ATA ┬YTES ▄
. ╬+1 ▄ ▄
. +--------------------+
╔F A SECTOR RETURNS A BURST STATUS CODE OTHER THAN 0 (OK) OR $1╞ (END), THEN
AN ERROR HAS OCCURRED AND THE DISK DRIVE ABORTS THE TRANSFER, CLOSES THE BURST
CONNECTION, AND STARTS THE DRIVE LIGHT BLINKING.
╘HE "BURST╥EAD" CALL OF THIS PACKAGE READS THE DATA OF THE NEXT SECTOR OF THE
OPENED FILE INTO THE "BURST┬UF" AND RETURNS THE "BURST╙TATUS" AND
"BURST┬UF├OUNT" (BYTES READ). ╔N THE EVENT OF AN ERROR OCCURING, THIS ROUTINE
RETURNS WITH THE CARRY FLAG SET AND THE TRANSLATED BURST ERROR CODE IN THE .┴
REGISTER (SAME AS BURST╧PEN). ╫HEN THE LAST SECTOR OF THE FILE HAS JUST BEEN
READ, THIS ROUTINE RETURNS WITH A VALUE OF $1╞ IN THE "BURST╙TATUS" VARIABLE.
3.3. ┬╒╥╙╘ ├╠╧╙┼
┴FTER READING THE LAST DATA BYTE OF THE LAST SECTOR OF THE FILE, THE BURST
CONNECTION AND IS CLOSED AUTOMATICALLY BY THE DISK DRIVE. ╘HE "BURST├LOSE"
ROUTINE IS NOT NECESSARY FOR COMMUNICATION WITH THE DISK DRIVE, BUT IS
PROVIDED FOR COMPLETENESS AND TO CLEAR THE INTERRUPT DISABLE BIT (├╠╔) THAT
THE OPEN ROUTINE SET TO PREVENT INTERRUPTS WHILE BURST READING.